IBIS Macromodel Task Group

Meeting date: 01 February 2022

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Cadence Design Systems:     * Ambrish Varma
                              Jared James
Google:                       Zhiping Yang
Intel:                      * Michael Mirmak
                              Kinger Cai
                              Alaeddin Aydiner
Keysight Technologies:        Fangyi Rao
                              Majid Ahadi Dolatsara
                            * Ming Yan
                              Radek Biernacki
                              Rui Yang
Luminous Computing            David Banas
Marvell                       Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Mike LaBonte
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
Missouri S&T                  Chulsoon Hwang
Siemens EDA (Mentor):       * Arpad Muranyi
Teraspeed Labs:             * Bob Ross
Zuken USA:                  * Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- Michael said he had discovered a possible complication related to the
  [Clock Pins] keyword.  He suggested that he could introduce the issue if time
  permitted.
  
- Michael said he had received lots of feedback about his presentation on
  extending [Test Data] to support AMI.  He said he would start a BIRD draft.

-------------
Review of ARs:
  
- Fangyi to review Walter's draft of BIRD 211.4.
  - In progress.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the January 25th
meeting.  Randy moved to approve the minutes.   Michael seconded the motion.
There were no objections.

-------------
New Discussion:

PAMn BIRD213.1:
Walter said he had no new updates or feedback to report.  Ambrish said he was
still reviewing it.  Randy said he had found a few typos in the most recent
draft and would report them to Walter.  Walter said he would post a new draft
addressing Randy's comments and would await any comments from Ambrish.  Randy
asked people to review the BIRD in anticipation of voting to submit it to the
Open Forum.

AMI Root Name Clarifications BIRD draft:
Michael shared the latest draft he had sent to the ATM list.  He said it
incorporated a change proposed by Mike LaBonte.  Mike had noted that previous
language referring to the "first ... line" in an AMI file was non-sensical
because the entire contents of the .ami file could reside on one line.

Michael said his suggestion was that the parser could call the executable model
functions and issue a warning if there is a mismatch between what the model
returns and the .ami file's root name.  He acknowledged that this would be a
non-trivial upgrade to the parser, as it does not currently call any of the
executable model functions.

Arpad said he thought the definition of "root name" as it pertains to what is
in the .ami file was okay now.  However, he said we might need to enhance the
definition to include a statement about the value that is "hard-coded" in the
executable model.  Arpad said the BIRD's new text in the AMI_parameters_out
section could be interpreted as saying that the model should return the value
that was passed into it.  He said we need to make it clear that the model
itself contains a hard-coded value that must match the root name of the .ami
file.  Michael suggested we could add the phrase "which shall be contained
within the executable model" to refer to the value returned by the model and
address Arpad's concern.  Randy agreed and noted that one tool he used to create
AMI models hard-coded the root name in the executable model, and if it were
passed the wrong root name from an .ami file it would fail.

Randy said he had some editorial suggestions.  He and Mike agreed to discuss
them offline.

Issue with the flexibility of [Clock Pins]:
Michael said he had run into an issue while trying to create a model that used
the [Clock Pins] keyword.  He reminded everyone that it is currently an open
ended keyword that associates pins with pins.  The first column of each row is
a clock pin, and the second column is a clocked pin that uses the first pin
(it might be a data pin, or another clock, etc.).  The third column can only
contain "Unspecified" for now and is reserved for future use.

Michael said his goal in introducing [Clock Pins] had been to give EDA tools a
hint about these clocking relationships.  This might allow them to automate
certain set-up steps.  For example, IBIS 7.1 includes AMI changes for clock-
forwarded architectures and allows one AMI model to get its clock from another
AMI model.  The problem is that this clock-data association can't be specified
at the AMI level.  We want the association at the IBIS [Pin] level.  For
example, [Clock Pins] might help an EDA tool automate setup of a bus simulation
with clock and data waveforms being simulated simultaneously and passed through
the flow.

Michael said he had run into an issue because these clock-data associations
might vary depending on device configuration.  For example, a x4 DDR
configuration might do data and strobe associations by nibble, where a x8
configuration used the same strobe for an entire byte.  So the clocking
relationships between pins would be different for x4 or x8 configurations.

Arpad asked if this was something that could happen in real time or was fixed by
the device's configuration.  Michael said a controller might expect to operate
differently depending on the DRAM devices it's connected to.

Randy said when they build memory it can be x4 or x8 and be the same piece of Si
in the same package, but they will sell it as x4 or x8 by blowing fuses or some
other physical change to lock it into one configuration.   So, that clock-data
relationship would be fixed for a given device.  At run time the system figures
it out by reading an EEPROM on the DIMM that stores the configuration
information.

Randy said when they create IBIS models, they use separate [Component]s for the
x4 and x8 configurations.  Since the [Clock Pins] keyword occurs inside the
[Component], the clock-data relationships defined by the [Clock Pins] keyword
are fixed.  Michael observed that if you're a DRAM manufacturer this works fine,
but if you're a controller manufacturer it might not ;-)

Arpad wondered if we might consider having multiple named instances of [Clock
Pins] keyword information.  Then a particular instance could be selected for a
given simulation/configuration.  Michael said this would be something like a
[Model Selector] approach.  Arpad said it was similar to [EMD Group]s.

Michael also suggested adding a 4th column to [Clock Pins] rows, which could
could serve as the selector.  Arpad said this was more like a [Series Switch
Group] approach, and he thought this was more cumbersome and repetitive than
having multiple instances of [Clock Pins].

- Ambrish: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.

AR: Walter to send out a new draft of BIRD213.1 addressing Randy's comments.

-------------
Next meeting: 08 February 2022 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
